feat(eval): add eval online-eval CLI commands - #1877

Adds the imperative `agentcore eval online-eval` surface (CLI only), following
the conventions established in the eval evaluator review (#1822).

    agentcore eval online-eval
    ├── create
    ├── get
    ├── list
    ├── update
    ├── pause      # executionStatus -> DISABLED
    ├── resume     # executionStatus -> ENABLED
    └── delete

Data source. `--agent` accepts a plain AgentCore Runtime ID or a Harness ID and
derives the CloudWatch source from it: a harness is itself backed by a runtime,
so resolution tries GetAgentRuntime and falls back to GetHarness, reading the
underlying runtime out of the harness environment. The log group is keyed by the
runtime *id* and the service name by the runtime *name* — verified against live
resources; the two are not interchangeable. `--data-source-config` takes the
API's DataSourceConfig as JSON for agents that emit traces under a custom OTel
service name, which no derivation can guess.

update takes the same two entry points plus an endpoint re-scope, in precedence
order: --data-source-config replaces the source outright, --agent re-derives it,
and --endpoint/--clear-endpoint re-scope the agent the config was already built
from (recovering its runtime id from the stored log group).

Merge semantics. UpdateOnlineEvaluationConfig does partial updates at the top
level — an omitted field is untouched — but sending `rule` replaces the whole
object, so the client merges the untouched sub-fields over the current config.
sessionConfig is optional on Rule and the service does not backfill it, so it is
omitted when unset rather than materializing the service's own default.

Flags are validated against the service model's documented ranges
(--sampling-rate 0.01-100, --session-timeout-minutes an int in 1-1440).
--data-source-config and --filters are source-aware (inline, file://<path>, or -
for stdin). --role-arn is required: the CLI does not provision an execution role.

Testing. Handler tests use the fixture/golden pattern (real CoreClient behind a
recorded SDK seam). The recording creates one config, exercises
get/list/update/pause/resume, then deletes it, so it leaves no residue. Beyond
the recorded flow, the following were exercised against the live API: file:// and
stdin sources, the one-stdin-per-command guard, all three update data-source
paths applied in sequence to one config, and the client-side rejection of
--endpoint on a config built from custom log groups.

CreateOnlineEvaluationConfig requires a role the service can assume, and the
policy it validates is not obvious: spans live in `aws/spans` rather than the
runtime's own log group, and query access must be scoped to the runtime log-group
*prefix* — a policy pinned to a single endpoint is rejected. Both took live
failures to pin down, surfacing only as "the provided execution role does not
have permissions to access the specified log groups", so leaving it to the caller
made `create` hard to use.

Core now provisions a default role scoped to the resolved log groups unless
--role-arn is passed, mirroring the harness execution-role pattern and the
design doc's auto-provisioning philosophy.

A freshly created role is not immediately assumable (IAM is eventually
consistent) and the service rejects the create rather than retrying, so the
create is retried on that specific error with a bounded backoff — only when we
provisioned the role, since a caller-supplied one that cannot be assumed is a
real misconfiguration and should fail fast.

Fixtures re-recorded: the create flow now captures the GetRole/CreateRole/
PutRolePolicy calls, and the recorded policy scopes to the runtime prefix.

Four fixes from @notgitika's review:

Role name (onlineEvalExecutionRole.tsx). `AgentCoreOnlineEval-` is 20 chars, so
slicing to IAM's 64-char cap kept only the first 44 characters of a config name
that can run to 100. Two configs sharing that prefix mapped to one role, and
because provisioning is idempotent by name the second create silently re-scoped
the first's policy to a different runtime. Long names are now truncated with a
hash suffix.

Role scope on update (eval.tsx). Moving the data source left the role scoped to
the old runtime, so sampling stopped with no error — the service validates the
role's log-group access on create, not update. A CLI-provisioned role (identified
by its derived name) is now re-scoped when the source moves; --update-role false
opts out. A role named via --role-arn is never edited, and update accepts
--role-arn so a caller can replace it. Both skip paths return a warning that the
handler prints to stderr, naming the role and the log groups it needs access to.

IAM endpoint leak (eval.tsx). The IAM client was built with toClientConfig, which
forwards --endpoint-url; IAM is global and must not receive the agentcore
override. Now passes { region } only, matching harness.tsx.

KMS (kms:Decrypt for encrypted evaluators) is deliberately not addressed here.

Verified against the live API: the policy re-scopes from one runtime to another
on --agent, --update-role false skips it and warns, and --role-arn leaves a
custom role's own policy untouched. The role-warning test lives in its own
describe with its own config, since adding a call to the CRUDL sequence shifts
which recording each of its calls keys to.

Wrapping the failure in InputValidationError mislabelled it: that type sets
source: USER, but a GetEvaluator call failing is not the caller's input at fault
— it is a service or permissions condition. It also replaced the SDK's error,
which already names the operation and the evaluator, with a less precise message.

The try/catch is removed so the original error surfaces unchanged.

Nico's review: re-scoping the managed role before UpdateOnlineEvaluationConfig
left the config broken if the update then failed — the role granted query access
to the new runtime's logs while the config still pointed at the old one, so it
silently stopped sampling.

The role is now widened to the union of old and new log groups before the update
and narrowed to the new set only after it succeeds. A superset role is valid for
either config state, so a failed update never strands a live config without
query access; a later successful update narrows it back. If the narrow itself
fails, a "narrow-failed" warning reports the role is broader than the current
data source (a real reason the handler now renders distinctly, rather than
mislabelling it as a declined re-scope).

Verified against the live API: a forced update failure leaves the config on the
old runtime with the role still covering it, and a successful --agent repoint
narrows the role to the new runtime only. Fixtures re-recorded for the two-step
PutRolePolicy sequence.

The transactional re-scope on update rewrote the role's single inline policy in
place (widen to the union, then narrow), so the pre-update scope existed nowhere
once the widen ran — an interrupted update left the role permanently over-scoped.

Each scope is now its own inline policy, named after a fingerprint of the scope:

- grantOnlineEvalScope attaches the new scope's policy (create path uses this too)
- revokeOnlineEvalScope detaches the superseded one

update grants the new scope, runs UpdateOnlineEvaluationConfig, then revokes the
old scope only on success. Because granting never overwrites another scope's
policy and IAM unions Allows across a role's inline policies, both scopes are
granted in between, and a failed update leaves the policy backing the current
data source byte-identical. Verified live: a forced update failure left the old
policy's md5 unchanged with the config still pointing at (and granted) the old
runtime; a successful --agent repoint revoked the old scope.

Also widens the create-time propagation retry: a freshly written policy under a
new name is not immediately visible, surfacing as "does not have permissions to
create log group" / "access the specified log groups" in addition to the
existing "role cannot be assumed". Renamed to retryWhileRolePropagates.

The stale-scope warning replaces narrow-failed: on update the concern is now a
superseded scope policy left attached, not a policy that could not be narrowed.